缘由
对于初次接触某个第三方库的C#开发者,假如要调用里面一个方法,发现需要一个A类型的实例作为参数,怎么获得这个实例呢?
我想大多数人会先尝试new A吧:
如果没有,可能会尝试输入A.看看有没可能的构造方法:
如果还没有,那一般要通过其他方式获得了(子类、其他方法的返回结果等)。就此打住,因为后面的不在此文讨论范围。
我就郁闷了,为何要我输入一次new之后发现没有,然后再次输入A.呢?
我指的是,最好让C#编译器支持这样的语法糖:A.new() 跟new A()等价。
本文不适合的阅读对象
文档帝:万事必先看文档的人,本文说明的东西与你无关。
键盘帝:不使用VS或者类似的智能提示的用户,本文说明的东西对你没什么影响。
好处是什么?
- “你不觉得输入一次new A之后删掉再输入A.这个过程很傻吗?” **
只需输入A.即可知道是否有构造函数,类似A.create这样的工厂方法,或者像A.instance这样的单例对象,列在一起更方便对比。
另外一个好处是,A.new 可以通过匹配参数类型来赋值给一个委托实例(Delegate)。
有什么可能出现的问题?
- “万一用户想创建一个名为new的方法怎么办?” **
毫无疑问,这种方式可能引起误解,以为这是一个静态方法,相当于类空间的命名被污染了。不过这种的说法是不成立的。
首先,假设A是个类型,当看到A.x()的时候,你觉得这是什么?事实上,你完全不能确定他是啥,可能是一个静态方法,也可能是静态属性,还可能是静态字段。所以,A.new()到底是什么本身就没可误解的地方。
其次,当用户想定义一个名为new的方法,实际上也是不可行的:
因为new是个关键字,要作为方法名的话,前面需要加@
调用时@也是不可省略的
所以,A.new()本来就是不能编译通过的,跟现有语法体系没有冲突。
对比起来,C#的自动属性才是真正的“污染类空间命名”,而附加属性也一定程度影响开发者的惯性思维,A.new()比起这些真的是小巫见大巫,语法糖而已。
- “反射的时候,会有问题吗?”
我觉得不会,Type.GetMethod的时候,本来就不包含构造函数。抽象类、接口、枚举这些东西,有new没new本身就是规则定好的,跟现有语法不混淆。
至于各种IDE的智能提示,作为规则支持就是了。
- “假如A的名字好长好长,就没new A()方便”
是的,当输入B.f(new空格后,可以看到A在列表里直接选择回车,这样敲的字符数是很少的。所以,new A()的方式完全可以保留。另外,提供一个智能提示,还记得事件绑定的那个snippet吗?
待补充
到此,我还是没想到把A.new()编译成new A()有什么坏处,关于这个建议如果各位有其他想法,不妨留个言?